Increasingly, videos are delivered to an IP playback device over a networked environment using the Hypertext Transfer Protocol (HTTP) via a series of HTTP request and response messages (“segmented HTTP transport (SHT) method”). For example, a video can be delivered to an IP playback device using HTTP by first partitioning the video file into a series of short video segments where each video segment can be placed on a server and identified by an unique Uniform Resource Locator (URL).
Each video segment typically includes 2 to 10 seconds of the video; however, the video segment can be longer or shorter than this range. An index file that contains information regarding how to retrieve the available video segments for a video is stored on the server and identified by an URL. The index file can include the respective URLs for the video segments or information to construct such URLs.
To play the video, software (“a client”) on an IP playback device first retrieves the index file from the server and then sequentially retrieves video segments from the server using the appropriate URLs. The IP playback device then sequentially plays the video segments on the integrated screen of the IP playback device or on a separately connected display.
More specifically, to play the video, the client can connect to the server and submit a HTTP request message (e.g., an HTTP GET request) to retrieve the index file for the video. The client can connect to the server by creating a (Transmission Control Protocol) TCP connection to port 80 of the server. The server then can send a HTTP response message to the client containing the index file for the desired video. Based on the information in the index file, the client can submit a series of HTTP requests to the server to retrieve the video segments needed to fill the video play out buffer. Initially, the HTTP requests may be submitted to the server at a rate faster than the actual play out. Typically, once the playback buffer in the client has reached a minimum target size, the client then sequentially submits HTTP request messages at the rate of the actual play out (for example every 2-10 seconds) to maintain at a pre-defined level the amount of available video segments in the playback buffer.
To support adaptive streaming, the server can store different versions of a video at different bit rates so that a client can download portions of the video at different bit rates as network conditions change. In some implementations, for example, the server stores the video segments at different bit rates and then the index file includes links to alternate index files for the video at the different bit rate streams. The client can switch to an alternate index file at any time during the streaming of the video as conditions warrant resulting in increased or decreased bit rate utilization on the access network.
In other implementations, for example, instead of storing multiple video segments and for each video segment storing different bit rate versions of the video segment, the server can store one file for each bit rate using, for example, the MPEG-4 Part 14 (ISO/IEC 14496-14) (“MP4”) file format or MPEG-2 transport stream (ISO/IEC 13818-1) (“MPEG2TS”) file format. Each MP4 or MPEG2TS file, which corresponds to the video at a particular bit rate, includes multiple video segments. The index file includes a list of the available bit rates for the video and the list of video segments for the video. To play video, the client sequentially requests video segments of the video at a particular bit rate. When the server receives the request, it extracts the MP4 or MPEG2TS video segment from the MP4 or MPEG2TS file corresponding to the requested bit rate and sends the requested MP4 or MPEG2TS video segment to the client.
End users increasingly desire to receive and watch videos on IP playback devices such as mobile devices including mobile phones, tablets, netbook, or notebook computers. However, the existing SHT methods for delivering videos are implemented independently for each playback device. That is, each playback device independently selects and requests a certain video quality (e.g., bit rate) for itself without consideration for the needs of other playback devices that share the same network resource(s). The intervening network or networks will attempt to deliver the requested video segments at the requested quality levels to the best of its ability. However, there may not be enough available resources to fulfill all the requests. In such an instance, the network may allocate less than the requested bandwidth to some playback device, while other playback devices are not fully utilizing the bandwidth allotted to them.
Accordingly, in a bandwidth-constrained environment, existing SHT methods implemented by one or more playback devices can cause video quality degradation for one or more other playback devices. For example, if one playback device wants to play new video or fast forward or rewind a video, the SHT method may attempt to quickly load or reload the playback device's playback buffer to allow the video to start or resume by requesting video segments at a higher bit rate. This type of unmanaged increase in bandwidth use from one or more playback devices can affect the ability of other playback devices to receive data thereby resulting in video quality degradation for these other playback devices. To avoid this result, existing solutions over-provision bandwidth for each subscriber premise. However, these solutions are inefficient and can be ineffective in reducing video quality degradation across playback devices.